データベース大規模,分散型データ管理のシステムアーキテクチャ実践編

システムアーキテクチャの方針

リアクティブアーキテクチャ https://qiita.com/crossroad0201/items/7c8892c459ecef39ccef

マイクロサービスを前提として、

必要な側面の全ては既に独立に認識されている: 求めるものは、即応性と、耐障害性と、弾力性と、メッセージ駆動とを備えたシステムだ。我々はこれをリアクティブシステム (Reactive Systems) と呼ぶ。 https://www.reactivemanifesto.org/ja

We believe that a coherent approach to systems architecture is needed, and we believe that all necessary aspects are already recognised individually: we want systems that are Responsive, Resilient, Elastic and Message Driven. We call these Reactive Systems.

https://gyazo.com/8e6659749b8ca0e22b1d9036151bcf08

マイクロサービスに分割する...だけではなく、リアクティブシステムであることがソフトウェアの必須要件

人ではなくデバイスが情報を収集して送信してくるようなサービスでは、サービスが停止してもデバイスは情報を送り続けようとします。

サービスが停止している間にも未処理のデータが溜まり続け、サービスが復旧してから溜まったデータを処理して追いつくことが難しくなることも考えられます。

アクターモデル https://ja.wikipedia.org/wiki/アクターモデル

The actor model in 10 minutes (https://www.brianstorti.com/the-actor-model/)

アクターモデルとAkka

https://tech-lab.sios.jp/archives/8738

並列処理プログラミング技法の1つです。マイクロソフトが提供しているマイクロサービス「Azure Service Fabric」や、LINEのメッセージ処理にも採用

アクターモデルを採用した有名なフレームワークに「Akka」があります。Akkaは、Scala及びJava向けに作られた、アクターモデルをベースにしたフレームワーク

https://gyazo.com/e94b9024129e8e139082f0551929da71

uberでは決済システムにAkkaを使っているらしい。そのAkkaのシステム・アーキテクチャの前提を強く受けている模様。

Shard https://en.wikipedia.org/wiki/Shard_(database_architecture)

分散型システムでは、ノードひとつで格納できるデータより、ずっと多くのデータを格納しなくてはなりません。一般的な方法は、シャーディングを使うやり方です。データを、パーティション割り当てを決めるある種のハッシュを使って、水平に分割します。多くの分散型データベースが内部に実装している( https://postd.cc/distributed-architecture-concepts-i-have-learned-while-building-payments-systems-2/ )

Quorum https://ja.wikipedia.org/wiki/Quorum

多くの分散型システムは、データや演算を複数のノードにコピーさせています。オペレーションが一貫した方法で実行されるようにするために、このうち一定数のノードで同じ結果が返されなければ操作が成功しない、という投票ベースのアプローチ( https://postd.cc/distributed-architecture-concepts-i-have-learned-while-building-payments-systems-2/ )

Cassandra

https://www.nttpc.co.jp/technology/cassandra.html がよい

appleは10ペタバイト以上のデータをCassandraのノードを使っていた

Cassandraは分散型のNoSQLデータベースで、CAP定理のAとP（可用性と分断耐性）の特性を基準に最終的な一貫性が確保されています。ただ、このように言ってしまうと少し誤解を招くかもしれません。というのも、実際のところCassandraの設定は非常に柔軟性が高く、可用性を犠牲にして強い一貫性を提供することもできるから ( https://postd.cc/a-thorough-introduction-to-distributed-systems-2/ )

Cassandraは、複数台でクラスターを組んで分散DBを作成し、スケールアウトすることが容易にできる構造になっています。また処理性能も構成するノード数に比例します。

Cassandraは、クラスター内で各サーバーの保持するデータの整合性が一時的に一致せずともそのうち整合性がとれれば良いEventual Consistencyという概念で出来上がっています。

リレーショナルDBでは、整合性の完全一致が必須ですが、Cassandraでは、Tunable Consistency という考え方でConsistency Levelを調整することにより変更もほぼない大量のデータを解析で処理する時などはConsistency Levelを下げることで処理能力を上げたりデータの最新性が必要な場合はConsistency Levelを上げるなど柔軟に設定する

Consistency Levelが「ONE」なっている時は、coordinatorになったノードから直近一つのノードにのみ接続がありますが「ALL」に設定されている時は、関連するすべてのノードへ接続し該当の処理が終わるまでDBシステムとしての処理は終わりません。( https://www.nttpc.co.jp/technology/cassandra.html )

https://gyazo.com/ff3e61bf0d06663ded6bad5704dc1e2d

実例集

cassandra https://cassandra.apache.org/?utm_source=xp&utm_medium=blog&utm_campaign=content

mongoDB https://www.mongodb.com/who-uses-mongodb?utm_source=xp&utm_medium=blog&utm_campaign=content

mongoDBとcassandra

https://www.xplenty.com/jp/blog/cassandra-vs-mongodb-ja/

Cassandraはよりスケーラビリティの高いMySQLスタイルのデータベースを求めている人に適しており、MongoDBは非構造化データの保存に最適

Cassandraには集計フレームワークがありません。管理者は、集計にHadoopやSparkなどのサードパーティ製ツールを使用する必要があります。

それに比べてMongoDBは、集計フレームワークを内蔵しています。これはETLパイプラインを実行して保存データを集計し、結果を返す

→cassandraが良さそう

symantecはoracle rdbからcasandraへ乗り換えている　https://www.slideshare.net/DataStax/oracle-let-my-people-go-shu-zhang-ilya-sokolov-symantec-cassandra-summit-2016

一貫性は結果的整合性で担保しておく。モデリングは工夫する必要があるし、アプリケーション側が頑張る必要はありそう。だけど、RDBから乗り換えて、低コストで高い拡張性を担保することができる。

cassandra, kafkaを組み合わせる

https://www.slideshare.net/DataStax/running-400node-cassandra-spark-clusters-in-azure-anubhav-kale-microsoft-c-summit-2016

https://gyazo.com/3048dc4b8a07299d0911cd981824e616

Hadoop

https://oss.nttdata.com/hadoop/hadoop.html　がよい

hadoopとは何者なのか？

大規模データの蓄積・分析を分散処理技術によって実現するオープンソースのミドルウェア

従来型のRDBMSやDWHと根本的に異なる点は、HDFSにデータを格納する際にはスキーマ定義が不要

構成要素

分散ファイルシステムであるHDFS(Hadoop分散ファイルシステム)と分散処理フレームワークであるHadoop MapReduceの2つから構成

HDFS

マスターノードであるNameNodeとスレーブノードであるDataNodeで構成されています。 NameNodeは分散ファイルシステムのメタ情報を管理し、DataNodeは、データの実体を保存

https://gyazo.com/58479c46160347c27a7b60bcf8020ed9

Hadoop MapReduce

Hadoop MapReduceは、分散処理を実現するMapReduce処理基盤と処理基盤上で実行するMapReduceアプリケーションの2つのコンポーネント

分散処理を実現するMapReduce処理基盤

マスターノードであるJobTrackerとスレーブノードであるTaskTrackerで構成されています。 JobTrackerは、MapReduceジョブの管理やTaskTrackerへのタスクの割り当て、TaskTrackerのリソース管理を役割としています。 TaskTrackerは、タスクの実行を役割

https://gyazo.com/2a2a19f29ac876c61e477537bd3ef429

Hadoop2系では、分散処理フレームワークHadoop MapReduceの仕組みが変更となり、分散リソース制御機構 Hadoop YARNとMapReduce ApplicationMasterの2つに分離されました。 YARNの登場により、MapReduceに適していない処理については、各自が仕組み(ApplicationMasterとアプリケーション制御)を実装することでMapReduceと同様にYARNの仕組みによって分散処理が可能

MapReduceアプリケーション

MapReduceジョブの一連の処理プロセスに責任を持つ

(1) map処理: 入力データに対して、何らかの処理によってキー・バリューの形式でデータを意味づける

(2) reduce処理: map処理のキーごとに集約されたデータに対して何らかの処理を実行する

(3) MapReduceジョブ定義: (1)と(2)を処理するための情報(入力パス、出力パス、reduce処理の多重度など)を定義する

https://gyazo.com/a6cada622960b2abfcd7b62fec206ff3

一貫性を取るのが難しのかな？

得意なのは、データまとまったデータ。小さな大量のデータではないかも？

yarnが出てきたことで解決した部分がある？

実例

（三井住友カードと日本総研）Hadoop導入のPoCからスタートし、メインフレーム上のバッチ処理の一部をHadoopにオフロード。CPU負荷を低減し、コスト削減を実現　https://oss.nttdata.com/case7_smcc.html

データ管理ではなくて、計算処理とかだけ外出ししているって感じ。

GoogleはMapReduce

Googleは増え続けるデータに対応するため、分散コンピューティングに関して新しいパラダイムを必要としており、それがMapReduceとなって実を結びました。2004年にその論文が発表され、その後、オープンソースコミュニティでは、MapReduceを元にApache Hadoopが作成されています。( https://postd.cc/a-thorough-introduction-to-distributed-systems-2/ )

2011年、Yahooは600ペタバイトのデータを保存するために4万2000以上のノードでHDFSを稼動させました。 https://www.slideshare.net/Hadoop_Summit/what-it-takes-to-run-hadoop-at-scale-yahoo-perspectives

Hadoop分散ファイルシステム（HDFS）は、Hadoopフレームワークによる分散コンピューティングに使用される分散型ファイルシステムです。（ギガバイトやテラバイトサイズなどの）大規模なファイルを多数のマシンに格納して複製するために使用されており、幅広い採用実績を誇っています。

kafka

https://oss.nttdata.com/kafka/kafka_solution.html がよかった。

バッチ処理って感じじゃなくて、ストリームで流れてくるものを、リアルタイムでスケールアウトしながら処理していくってのが強いんだと思った。

LinkedInのKafkaクラスタは、1日に1兆件のメッセージ（ピーク時には1秒あたり4500万件のメッセージ）を処理しました。 https://engineering.linkedin.com/apache-kafka/how-we_re-improving-and-advancing-kafka-linkedin

https://techblog.yahoo.co.jp/entry/20191216789293/

https://oss.nttdata.com/kafka/kafka.html

Kafkaはシステムにおいてストリームデータの中継役を担います。ストリームデータとは継続的/連続的に生成されるデータの集合のことです。機器の動作情報/APサーバのログ/ECサイトの購入情報/SNSの投稿など様々なデータをストリームデータとして扱うことができます。

機器やサーバとデータの処理サーバなどの間に配置され、生成されたストリームデータを受け取り、一時的にデータを保存しつつ、都度または必要なタイミングで処理サーバにデータを受け渡します。

https://gyazo.com/906911d753b960e62ec24378b80f1615

データの消失リスクへの解決策もあるのがいいみたい

--.icon

hadoop, cassandra https://www.unisys.co.jp/tec_info/tr111/11106.pdf

https://gyazo.com/e2ab9c104d9bcbb2fdf43c88817f8cc8

https://gyazo.com/aaa627bee33c9041b130b3c0386e0c5a

kafka, cassandra

https://www.datastax.com/dev/kafka が良さそう